What changed

This fixes the remaining #307 Windows one-click apply path after v1.5.8 restored startup and ZIP import.

There are seven fixes in this PR:

• installer bootstrap still uses {sysnative} for Setup-owned PowerShell execution, but persistent shortcuts and the HKCU dreamskin:// protocol command now use {win}\System32\WindowsPowerShell\v1.0\powershell.exe, which 64-bit browser/Explorer launchers can access
• the Windows community-apply parser accepts both the site-generated URI dreamskin://apply?version=ver_... and the Windows/browser-normalized URI dreamskin://apply/?version=ver_...
• Windows theme loading/application is aligned with the shared community theme contract used by macOS: current community packages use colors; Windows no longer requires, creates, reads, or emits the old palette runtime field in its PowerShell store / injector path
• standalone Windows Verify now dot-sources theme-windows.ps1, so it can resolve Get-DreamSkinThemePaths and verify the active theme directory outside the tray/start scripts
• one-click community apply no longer waits unboundedly for the hidden start/verify child process; the parent handler now waits with the existing operation timeout and returns a visible error instead of leaving a no-window protocol handler hung indefinitely
• Windows visible renderer verification now matches the macOS home-route gate: it still requires exact payload revision, visible document/window evidence, real shell/home structure, and visible hero content, but it no longer rejects a valid home route solely because the suggestions area has a non-2..4 card count
• Windows startup now mirrors macOS after an initial visible-verification miss: activate the existing Codex window, force one --once apply of the exact active theme, then verify again before deciding to rollback

The protocol parser remains fail-closed for non-canonical inputs: extra parameters, fragments, uppercase scheme/version IDs, double-slash paths, arbitrary paths, and URL/path injection are still rejected by regression tests.

Why

#307 reporter confirmed on Windows 11 + Chrome that v1.5.8 restored startup and ZIP import, but one-click apply still fell back to the website's “client not detected / download ZIP” hint.

Windows-side testing then showed separate layers:

1. 64-bit browsers can fail to launch a registry command that uses Inno's {sysnative} path.
2. Once the handler process starts, Windows/browser handoff may pass the URI as dreamskin://apply/?version=..., while the old parser accepted only dreamskin://apply?version=....
3. After protocol handoff/download/import succeeded, applying some current community packages could fail because the Windows PowerShell theme store assumed a palette property that is not part of the current shared community schema.
4. Standalone Verify could fail with Get-DreamSkinThemePaths is not recognized because it loaded common-windows.ps1 but not theme-windows.ps1.
5. The one-click handler's hidden parent process used Start-Process -Wait for start-dream-skin.ps1; if that child process did not exit cleanly after renderer recovery/final verification, the protocol handler could sit with no visible window for minutes even though rollback/final state had already completed.
6. Later real Windows smoke on 74927d4 proved the previous layers were fixed, but the final target theme still failed visible verification and rolled back cleanly to Gothic Void Crusade. This exposed two Windows/macOS behavior gaps: Windows had an older fixed 2..4 home-card verification gate, and Windows did not do macOS's activate + forced one-shot retry after the first verify miss.

CI / validation

Latest PR head at the time of this note: 71c3ca9.

Local checks before push:

• node --check windows/scripts/injector.mjs
• node windows/tests/injector-window-readiness.test.mjs
• node windows/tests/injector-bootstrap.test.mjs
• node windows/scripts/injector.mjs --check-payload --theme-dir <downloaded ver_6e5527257d304daca9d5 package>
• git diff --check
• static assertions for the protocol handler path, colors/no-palette Windows payload contract, standalone Verify dependency, bounded one-click start verification, Windows/macOS-aligned home verification, and activate + forced once retry

CI must pass on the latest head before merge. Earlier CI run 30528814057 passed on 74927d4; a newer run is required for 71c3ca9 because this PR now also changes Windows renderer verification and startup retry behavior.

Windows AI verification notes / 给 Windows 测试 AI 的说明

Scope: this PR verifies the Windows one-click flow for #307 from browser handoff through native confirmation, download/import, applying a current community theme, visible renderer verification, and bounded handler exit. Do not close #307 from this PR alone; after release, affected users still need to confirm recovery.

1. Checkout and confirm exact PR head

gh pr checkout 317
git rev-parse --short HEAD

Expected head at the time of this note: 71c3ca9 or newer.

2. Run source-level Windows checks

From the repository root:

powershell.exe -NoLogo -NoProfile -ExecutionPolicy RemoteSigned -File .\windows\tests\run-tests.ps1
powershell.exe -NoLogo -NoProfile -ExecutionPolicy RemoteSigned -File .\windows\tests\installer-static.tests.ps1

These must pass. Relevant coverage:

• windows\tests\community-theme-link.tests.ps1: accepts canonical and Windows-normalized dreamskin:// URI forms, rejects unsafe forms, and asserts the one-click hidden start/verify child has a bounded wait
• windows\tests\theme-zip-import.tests.ps1: imports and applies current community/Studio packages without introducing legacy palette
• windows\tests\injector-window-readiness.test.mjs: verifies Windows native-window fallback, exact payload binding, and macOS-aligned home verification without a fixed suggestion-card count
• windows\tests\run-tests.ps1: validates the Windows injector payload does not drift from the shared community theme contract, confirms standalone Verify loads the theme-store helpers it calls, and asserts startup has activate + forced --once retry after an initial verify miss

3. Build a local Setup.exe from the PR

If Inno Setup 6 is installed:

$output = Join-Path $env:TEMP 'codex-dream-skin-pr317'
$iscc = Join-Path ${env:ProgramFiles(x86)} 'Inno Setup 6\ISCC.exe'
powershell.exe -NoLogo -NoProfile -ExecutionPolicy RemoteSigned `
  -File .\windows\installer\build-release.ps1 `
  -OutputDirectory $output `
  -IsccPath $iscc
Get-ChildItem $output -Filter 'CodexDreamSkin-Setup-v*.exe'

4. Install/upgrade safely

Before running Setup.exe, close Codex and exit the Codex Dream Skin tray. The installer intentionally refuses to proceed while Codex is running; that refusal is a safety guard, not a PR failure.

Run the PR-built Setup.exe and complete installation.

5. Verify the registered protocol command

After installation:

$command = (Get-Item 'HKCU:\Software\Classes\dreamskin\shell\open\command').GetValue('')
$command
if ($command -notlike '*\Windows\System32\WindowsPowerShell\v1.0\powershell.exe*') { throw 'Protocol handler is not using System32 PowerShell.' }
if ($command -like '*sysnative*') { throw 'Protocol handler still uses sysnative.' }
if ($command -notlike '*apply-community-theme.ps1*') { throw 'Protocol handler does not point at apply-community-theme.ps1.' }

Expected: the command contains \Windows\System32\WindowsPowerShell\v1.0\powershell.exe, does not contain sysnative, and points to the installed apply-community-theme.ps1 under %LOCALAPPDATA%\CodexDreamSkin\engine\scripts.

6. Verify standalone Verify no longer misses theme helpers

After installing and starting DreamSkin once, run:

powershell.exe -NoLogo -NoProfile -ExecutionPolicy RemoteSigned `
  -File "$env:LOCALAPPDATA\CodexDreamSkin\engine\scripts\verify-dream-skin.ps1"

Expected: it must not fail with Get-DreamSkinThemePaths is not recognized. A renderer mismatch or Codex-not-running error is a different runtime state issue; classify it separately.

7. Verify both URI forms reach the native handler

Use either Win + R manually or PowerShell ShellExecute:

Start-Process 'dreamskin://apply?version=ver_6e5527257d304daca9d5'
Start-Sleep -Seconds 2
Start-Process 'dreamskin://apply/?version=ver_6e5527257d304daca9d5'

Expected: DreamSkin native confirmation dialog appears. Cancel is acceptable for this handoff check; the important part is that the native dialog appears for both URI forms.

8. Verify browser handoff and full one-click apply

Open Windows 11 Chrome or Edge and click 一键换肤 on either:

• https://dreamskin.cc/gallery
• https://dreamskin.cc/preview?themeVersion=ver_6e5527257d304daca9d5

Expected full flow:

1. browser hands off to Windows / DreamSkin
2. DreamSkin native confirmation dialog appears
3. after confirmation, metadata is fetched from the fixed API
4. ZIP downloads and imports
5. selected community theme is applied to Codex
6. no error like The property 'palette' cannot be found on this object
7. no final error The imported theme failed visible verification. The previous theme was reapplied and visibly verified. for ver_6e5527257d304daca9d5
8. the protocol handler exits with a success dialog or a visible bounded error; it must not remain as an invisible/no-window process for more than the operation timeout

Important Chrome note: if the user previously selected “always allow/open this app”, Chrome may no longer show the browser external-app prompt. That is not automatically a failure. The pass/fail signal is whether the DreamSkin native confirmation dialog appears and the apply operation completes.

9. If it fails, classify the exact stage

Please report one of these with screenshot/logs:

1. Browser click does nothing and no DreamSkin process/dialog appears.
2. Browser or Start-Process launches PowerShell, but no DreamSkin dialog appears.
3. DreamSkin confirmation dialog appears, but metadata/download/import fails.
4. Import succeeds, but applying the saved community theme fails.
5. Apply transaction succeeds or restores the previous theme, but the no-window protocol handler process does not exit.
6. Standalone Verify fails with Get-DreamSkinThemePaths is not recognized.
7. Target theme is written, but final visible verification fails and rollback succeeds.
8. Confirmation appears and apply succeeds.

Case 1/2 is still protocol handoff. Case 3/4 is a later handler/import/apply-stage issue and should include the DreamSkin error dialog text. Case 5 is the bounded child start/verify wait path changed by this PR and needs process/log evidence. Case 7 is the visible-verification path changed by 71c3ca9; include %LOCALAPPDATA%\CodexDreamSkin\verify.log, injector.log, and injector-error.log if available.

Notes

• This PR does not include a release/version bump.
• Keep this PR draft until a real Windows one-click apply smoke test confirms the browser click reaches native confirmation, applies a current community theme, and the protocol handler exits or returns a visible bounded error.